The subject system and method are generally directed to automatically establishing a user-friendly, efficient, and effective debugging environment for electronic design automation (EDA) software environments. The system and method provide automated measures for interacting with a developer, providing a user with a debugging environment that is automatically generated responsive to a designer merely selecting an object or cell in a design. The system and method automatically determine which other cells in a hierarchy are required by the selected cell, locate their source code portions and the source code for the selected cell, and form a set of source code portions therefrom. Once the set of source code portions has been established, at least one breakpoint is set at a location of the source code for the selected cell. The set of source code portions may then be executed to generate at least one parameter for the selected cell. Upon reaching the set breakpoint, a debugging user interface is provided to the user that displays at least the source code for the selected cell and a value of the parameter therefor. Additionally, controls that provide the user with selective control over the progression of the execution of the source code of the selected cell may be provided. The system and method thereby enable and provide an automated debugging environment for hierarchical cell development.
As electronic design automation (EDA) and circuit design are becoming more and more intricate and complex, the demand for interoperability of designs, design houses, and support products is increasing. Re-usability of code, schematics, and quick, efficient, and potent debugging and designing tools are becoming increasingly essential. In performing the layout or silicon realization by a designer, such a task is rarely manually performed, but is instead automated through the use of parameterized cells (PCELLS including SKILL PCELLS and PyCells, for simplicity used interchangeably herein though PyCells may be implemented with minor differences, such as by a python language). PCELLS are not statically defined objects, but instead are dynamically defined, at least in part, by portions of source code which may be written in SKILL, Python, Tool Command Language (Tcl), SCHEME, Lisp, C, C++, Java, or any computer programming or scripting language as known to one of skill in the art (using library functions from Component Description Format (CDF) or Interoperable CDF (iCDF)). While the source code for a given PCELL is generally written in SKILL or a Lisp-based language, the source code for a PyCell is generally written in Python. The PCELLS are generally instantiated dynamically according to callback functions defined by their source code and according to parameters that are passed to the source code during instantiation. The parameters may illustratively come from a user, an application, a debugger, or from an evaluation of other PCELLS/PyCells. To achieve design goals, a hierarchal PCELL may be created to have a hierarchy of layers of PCELLS therein collectively forming the hierarchical PCELL. The PCELLS on a given level n, may, illustratively, receive parametric input from PCELLS on levels n, n-1, n-2, n-3 . . . etc.
Such PCELLS/PyCells are generally provided by a fabrication house or foundry, such as, for example: Taiwan Semiconductor Manufacturing Company (TSMC), which may often provide a collection of PCELLS or PyCells as a process design kit (PDK), interoperable PDK (iPDK), PCELL/PyCELL library, or library of components to be used to form any cell in a given design. A PDK developer for a fabrication house will create this PDK for an end user, such as a circuit layout designer, who will use the PDK or library to automatically generate, for example, a layout based on a circuit schematic, adding in parameters, as needed, for the design relying on the PDK. Therefore, for a circuit designer to successfully generate a layout with the PDK, a PDK developer will need to debug mistakes or errors in the PDK which would propagate in to the layout generation. The system and method may indeed be employed to enable and facilitate automated debugging in any environment that employs dynamically instantiated hierarchical objects. The present invention is not limited by the exemplary computer programming languages illustrated herein, data formats, or exemplary application packages featured herein.
Conventionally, a developer of the PDK would need to generate and inspect a test layout, find the errors or mistakes, and determine which PCELL the mistakes or errors belong to. Then, the developer would need to attempt to locate (within a vast library of different PCELLS and source code files) where the particular source code portion which instantiates instances of that PCELL and/or sets parameters of that cell is located. The developer would then need to open the correct source file, traverse to the portion relating to the problematic PCELL, manually insert a break point, and establish a debugging interface which will execute the PCELL source code in a debugging mode. While this may seem a trivial matter, many factors, layers, levels, transformations, languages, and abstractions complicate the matter. Indeed, the original source code for the PCELL objects may be transformed from its original form into an intermediate representation and then obscured in a database format in this transformed manner at run-time. In an exemplary definition of a PCELL, the source code for the PCELL may be extracted, converted, and placed inside a procedure of a debugging engine, such as SKILL, and stored in a database, such as, for example, an OpenAccess Database. Additionally frustrating the debugging, the source code for the PCELL may make calls to PCELL support files which are not contained in the source code for the PCELL and are, therefore, not located in the database. Therefore, it is no small task to locate and debug the source code, support files, and interdependencies for a particular PCELL that can be buried in any of potentially thousands of source code files.
In the event of an error during the test layout generation, a developer, conventionally, has been forced to abandon the layout, search through massive amounts of code to locate where the problem is, and attempt to debug the situation manually through the insertion of break points, callouts, traces, and other such debugging tools and measures, as known to one of skill in the art. Such distractions can prove costly and time consuming in the overall EDA design flow, especially considering the iterative nature of such a design flow. Such problems are naturally exaggerated and compounded when the layout contains parameterized cells (PCELLS) such that the characteristics or parameters of a given PCELL are not fully established until the layout is actually generated. When a developer chooses or is required to make use of PCELLS within PCELLS, nested PCELLS, or a hierarchy of PCELLS, the situation becomes exponentially more complex given the fact that any PCELL may have parameters that are determined by an evaluation of other PCELLS within the hierarchy of PCELLS. Such a design, while providing many benefits stemming from the dynamic nature, may resemble a complicated web of intricate interdependencies.
There is therefore a need for a system and method for automatically debugging PCELLS in a layout. There is a need for a system and method which provide an interface for a developer to select a problematic PCELL and have the source code files related thereto automatically identified and displayed. There is a need for a system and method to automatically determine interdependencies in a hierarchical PCELL. There is a need for a system and method to automatically generate, traverse, and evaluate the interdependencies within a hierarchical PCELL to correctly generate parameters for a selected PCELL. There is a need for a system and method to set a breakpoint in a source code portion for the selected PCELL, load the source code portion, and present the relevant portion to the user while intelligently omitting portions of the source code which the user did not code or which are unlikely to be of interest. There is a need for a system and method to automatically set a break point at a relevant portion of the located source code for the selected PCELL and provide the user with an integrated debugging environment to enable the developer to evaluate and remedy problems with the source code such that the generation of a layout or circuit realization may be efficiently debugged while not adding substantial distractive and interruptive tasks for an otherwise efficiently engaged developer. It is to be understood that the description of the exemplary embodiments below are not intended to limit the scope of the present invention to EDA embodiments or to any particular environment, application, language, or format.